This invention relates generally to computer graphical user interfaces, and more particularly relates to a graphical user interface having an object viewer that allows a user to view and edit multiple objects having the same properties.
Software developers typically have all the tools used by the developer to generate software under one umbrella, called an integrated development environment (IDE). IDEs provide an environment wherein the appropriate tools needed for source code editing, compiling, linking, testing, debugging, and profiling are comprehensively integrated. The IDE allows the developer to move from one phase of code development to another. Typically IDEs track code generation and, at the appropriate phase, invoke the necessary tool. There are many IDEs that can build, edit, compile, dynamically and statically analyze programs, configure, browse for source code, and debug, etc. An IDE called Eclipse may be used in a myriad of computer languages for software development.
Application program interfaces (APIs) allow software developers to use the many functions inherent in a computer and operating system without having to directly keep track of all the details of a computer and its operating system. The operating system, connected to drivers for the various hardware subsystems, manages the changing details of the hardware; the programmer simply writes code for the API and trusts the operating system to create a file that allows random access to its data, obtain the location of the first available free storage location in the disk drive or other memory, write the file identifier at the beginning of the file, set up the permissions, and include other information that binds the file to the application. Just as the API provides a consistent way for applications to use the resources of the computer system, a user interface (UI), such as a graphical user interface (GUI), brings structure to the interaction between a user and the computer. The user interface is a program or set of programs that sits as a layer above the operating system itself.
The way an operating system knows about the data in the computer is by metadata. Metadata is data about data and is distinct from the data itself. Within the computer industry, the most common domain of metadata is the file system. Files contain data along with the data's metadata. Metadata may be immutable or independent, and metadata may further be essential or nonessential.
Immutable metadata changes only when the data itself changes. The nature of the file's data is immutable metadata and refers to the file's content type or type, such as whether the file is executable, image, audio, video, text, etc. and/or specific file formats such as JPEG, AIFF, MPEG2, etc., or even very specific versions of particular formats. A file's type, by definition, cannot change unless the data itself also changes. One case where immutable metadata may change without requiring a change to the data itself is a change, either an increase or decrease, of the file's accuracy. Data about modification of the file is mutable metadata whose accuracy can also increase to, for instance, the millisecond when the file was changed.
Independent metadata, the most common type of metadata, may change regardless of whether the data in the file also changes; for instance, changing the number of permissible users or changing a file's location does not necessarily change the actual data within the file. Creation date and possibly the last access data, assuming read-only access, also may change without changing the data.
Essential metadata is required to access a file, vis a vis a file's name, location, and size are essential metadata because the file cannot be used without them. Metadata is nonessential if the file's data can be retrieved and stored without knowledge of the file type metadata. File dates are nonessential metadata; there are many dates to associate with a file. File creation date, date of last data modification, date of last metadata modification, date of last data access, etc. File permissions inform the operating system and the user who can read this file, who can write to the file, who can execute the file, etc. Permissions and ownership metadata are nonessential and are determined by the security model of the operating system: user/group id numbers, permission bit masks, access control lists, etc. Permissions are usually stored on object systems and intended to be used with networked and/or multi-user operating systems. Because file date storage is so common, there is almost always a logical home for permissions to be stored with the file dates in the dedicated metadata structures of the file system. File ownership usually accompanies file permissions. Unix, for example, traditionally regulates file access by assigning rights to the file's owner, the file's group, and everyone else. In such an implementation, the permissions metadata is useless without the owner and group metadata.
A property viewer is a graphical user interface that displays the properties, attributes, or details of a file. It is sometimes called an attributes or a details viewer. A typical object is an arrangement of data, such as a file, and typical properties may include the object's metadata. A typical property viewer 110, as in FIG. 1, presents a table for each object; in this case the object's name is ASFormatter.cpp, set forth at 120 and is an object of the type “file,” as set forth in 128. The table typically has two columns: cells in the first column 140 set forth the name of the property; and cells in the second column 150 describe the value of that named property. In FIG. 1, the properties and the respective values of the object are: filter string 112 d:/examples/* 172, that the object is not hidden 114, 174; the date of last modification 116—Day/Month/Year Time 176; the object's location 118 at d:/examples 178; the object's name 120 ASFormatter.cpp 180; the number of children 122 being zero 182; that the object is not a read-only file 124, 184; the size of the object 126 being 51429 bytes 186; and the type of object is a file 128, 188. The type of the input object to a property viewer determines what properties are to be displayed. Generally the properties viewer provides a means of editing particular properties, i.e., the values of the object's properties.
The properties viewer of FIG. 1 is generic, meaning that any user interface object can use the properties viewer so long as the object implements or accesses a property adapter. A property adapter is an application program interface or program driver for a property view. The property adapter obtains the property descriptors, provides access to the property values, and allows a software developer or user to set or edit the property value for a type of object. Using the common interface, the property viewer displays and allows a user to edit property information.
A content viewer is a viewer that displays the contents or data of objects. In the same way that a property viewer uses property adapters, a content viewer uses content adapters to determine how to display the content of an object. One example of a traditional content viewer is a hierarchical tree viewer as in FIG. 2 to display the children or the content of a particular parent node. In FIG. 2, the objects are nested within the hierarchical tree 210 and include file objects gmon.out 244, makefile 246, payroll.dat 256, and payroll.exe 258. Then, there are three other objects payclass.hpp 248, payfunc.hpp 252, and payroll.cpp 254. All these objects are in a file payroll 230, which is also considered an object. Payroll 230 and sys2 260 are children of demo 218, which, along with objects bug 216, astyle2 214, are children of the object examples 212.
User interface objects may use both a property adapter and a content adapter, shown respectively in FIGS. 1 and 2. The viewer determines which adapter to use, i.e., the property viewer uses a selected object's property adapter to display properties of the object. A content viewer uses the selected object's content adapter to display its content, sometimes referred to as the object's children. But it is often useful to be able to compare properties of a family of objects. Previously, a user had a choice to see the children of an object and then to open up each child to determine if one child had any properties in common with other children of the same object; that is, a user could either look at an object's content or she/he could look at the properties of individual objects—but not both.